Question — shipped store backend: This PR adds the MemoryManager machinery and the MemoryStore protocol, but no concrete store implementation. The TS side ships BedrockKnowledgeBaseStore (under strands-ts/src/vended-memory-stores/), and the design doc references an InMemoryMemoryStore for prototyping. As it stands, a user can't actually use this feature without writing their own store first, and there's no integration test exercising a real end-to-end path.

Is a concrete store (and an integ test) following in a separate PR? If so, a one-line note in the description would set expectations. If this is meant to be usable on its own, shipping at least an in-memory store would make the feature self-contained and give the suite an end-to-end anchor beyond the unit-level fakes.

Process note — API review label: This PR introduces a substantial new public API surface — a new top-level strands.memory package, the MemoryManager primitive, the MemoryStore protocol that customers implement, and ~10 new exported types/dataclasses. Per team/API_BAR_RAISING.md, a new customer-facing primitive/abstraction falls under "substantial changes," which calls for an explicitly designated API reviewer (or team consensus) rather than standard PR review alone.

The PR description does an excellent job documenting use cases, signatures, and the asyncio deviation — that's exactly the proposer prep the doc asks for. Could you add the needs-api-review label so this gets the appropriate sign-off before merge? Also worth confirming the divergence from designs/0011-memory-manager.md is intentional (the design doc describes store_memory/injection/EvictionTrigger; this port mirrors the current TS surface — add_memory, no injection — which seems correct, but the design doc status is still "Proposed").

Assessment: Comment

A clean, well-documented port. Tests pass (106), ruff and mypy are clean, the implementation faithfully mirrors the current TS surface, and the asyncio adaptation is thoughtfully reasoned in both the code and the PR description. My feedback is concentrated on the event-loop lifecycle defaults and process, not the porting work itself.

Nicely structured, well-tested work — the whole-object equality assertions and case-for-case TS parity make the suite easy to trust.

Assessment: Comment (approve — code is solid; design follow-ups are maintainer/author calls)

Reviewed 20a5a5e6 ("address review nits in coordinator and docstrings"), which responds to @pgrayy's review. The changes are clean and the nits are well-handled:

• process() → sync returning asyncio.Task | None (per the memory-optimization nit) — verified there are only two callers, schedule() and the test suite, and both were updated. schedule() no longer double-wraps in create_task, and the tests now route through a small _drive() helper that awaits the returned task. No stale await process(...) remains.
• Dropped the assert extraction is not None in favor of a graceful if extraction is None: return. Good call: I confirmed the coordinator is only ever constructed from _extraction_stores, which is pre-filtered on extraction is not None (memory_manager.py:195), so the branch is genuinely unreachable in production. Tightening the field type (the alternative suggested) isn't viable since MemoryStore.extraction must stay | None for non-extraction stores — the early return is the right resolution.
• _write now takes extractor as an explicit param rather than re-deriving it and re-asserting — removes the second assert and reads more directly.
• _block_kind no longer special-cases "text" — correct, every content block is a single-key mapping, so the generic path already covers it.
• Docstring trims (the snake_case note, the ExceptionGroup/3.10 rationale) — agreed these were implementation/translation context that didn't belong in shipped docstrings.

Re-verified on 20a5a5e6: 108 memory tests pass, ruff and mypy clean.

From my side the code is in good shape and all actionable review nits on this commit are addressed; the remaining items are design conversations for the team.

Assessment: Comment (approve — pure documentation commit, no behavioral change)

Reviewed 97b70025 ("docs(memory): tighten verbose docstrings and comments") — 7 files, +208/−606.

I verified this is genuinely docs-only: I stripped all docstrings via AST from both 20a5a5e6 and 97b70025 and diffed the resulting executable code. All 7 files are byte-for-byte identical with docstrings removed (coordinator.py, model_extractor.py, triggers.py, extraction/types.py, memory_manager.py, types.py, exceptions.py). No logic, signatures, or control flow changed.

The trims condense some genuinely verbose prose (e.g. the multi-paragraph "how it works in three pieces" module docstring) into tighter summaries, while preserving the key concepts a reader needs — the per-store high-water mark, the per-store task chain serialization, backoff/probe behavior, and the never-raises guarantee. This is a net readability win.

Re-verified on 97b70025: 108 memory tests pass, ruff and mypy clean.

No code concerns. Position unchanged — the code is in good shape; the remaining open items are the design conversations in @pgrayy's review thread.

Assessment: Comment (approve — one-line docstring restore, no behavioral change)

Reviewed 16cf1e03 ("docs(memory): restore flush() concurrent-save note") — a single docstring line in coordinator.py.

This restores the "also waits out saves that start while waiting" note on flush(), which the previous trim had condensed away. Good follow-up — it brings back the one genuinely useful detail (that flush() re-checks for saves kicked off mid-wait) without reintroducing the verbose prose.

AST-strip confirms 9d8851c5 vs 16cf1e03 is identical executable code. Re-verified: 108 memory tests pass, ruff and mypy clean.

No concerns. Position unchanged.